System and Method for Ensuring Minimal Control Delay to Grouped Illumination Devices Configured Within a Wireless Network

ABSTRACT

A lighting control system and method is disclosed for not only controlling visual content loaded within a group set of illumination devices configured within a wireless network, but also for ensuring minimal control delay to those grouped devices. The lighting control system can include a lighting controller device that controls a plurality of lamps within a mesh network, not only to group those lamps but also to assign content to lamps within that group. The combination of a guaranteed groupcast to each of the group of lamps and an acknowledge back from those lamps that is aggregated over a single path achieves the improved lighting control system disclosed herein.

CROSS REFERENCE TO RELATED APPLICATION

This application is related to co-pending application filed concurrentlyherewith under Ser. No. 15/041,166, entitled “Device, System and Methodfor Controlling Visual Content Loaded Into A Grouped Set of IlluminationDevices Configured Within A Wireless Network.”

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to illumination devices and, more particularly,to illumination devices interconnected by a network and controlled basedon groupings of those devices and content stored therein.

2. Description of the Relevant Art

The following descriptions and examples are provided as background onlyand are intended to reveal information that is believed to be ofpossible relevance to the present invention. No admission is necessarilyintended, nor should be construed, that any of the following informationconstitutes prior art impacting the patentable character of the subjectmatter claimed herein.

A certain type of illumination device, known as light emitting diodes(LEDs) for illumination are becoming increasing popular in manydifferent markets. Accordingly, the use of the term illumination devicehereinafter refers to a lamp that is based on the use of one or moreLEDs. LEDs provide a number of advantages over traditional lightsources, such as incandescent and fluorescent light bulbs, including lowpower consumption, long lifetime, no hazardous material, and additionalspecific advantages for different applications. Of particular importanceis that for general illumination, LEDs provide the opportunity to adjustthe color or the color temperature to produce different lightingeffects. For example, effects such as tint, vibrancy and brightness canbe adjusted through the use of lamps based on lamps having LEDs. Thecolor, color temperature and lighting effects can also be modified as afunction of time in accordance with what is known as the circadianrhythm, or can be modified to produce different lighting scenes or, as afunction of time, lighting shows.

Another advantage of the use of LED lamps is that the lamps can beconfigured to communicate with one another wirelessly. The color, colortemperature and lighting effects can be modified through use of awireless network of lamps placed within a residence. As notedhereinafter, a residence is any structural dwelling that contains atleast a portion of the network of lamps that are interconnectedwirelessly and can be controlled by a user within that residence orcoupled to the residence by, for example, the internet.

The various types of networks that interconnect devices in general arefairly well known and documented. However, it is not until recently,since the advent of LED-type lamps, that lamps can be more readilycontrolled through wireless personal area networks (WPANs). Due to thenature of the solid-state control mechanism of LEDs, command signals canbe sent across the wireless network to adjust, for example, color,brightness or lighting effects. However, the primary purpose of suchnetworked lighting control systems is to be able to group the commandsbased upon sensor readings taken at one or more of the networked lampsin order to make the adjustments specific to a group within the network.Such network lighting control systems recognize that it is unfeasible toassign scenes to a group of lamps interconnected through a network sinceit is burdensome for a user to do so and because there is an almostinfinite number of possible lighting scenes. Thus, many of thenetwork-based conventional lighting control system take readings of thesurrounding environment (e.g., whether it is light or dark within theroom) and adjust a specific group of the networked lamps accordinglybased on the sensor readings, and not based on scenes that are assignedto the group. See, for example, U.S. Pub. Nos. 2013/0285574 and2014/0167623.

It is therefore desirable to implement lamps having LEDs that areinterconnected through a WPAN, and which can be controlled in anyfashion to adjust brightness, color or any lighting effect, eitherstatic or as a function of time, without necessarily relying on theconventional mechanism of using the LEDs for sensing the surroundingenvironment and adjusting the network control accordingly. A need existsfor using an improved broadcast mechanism to specific groups of lamps,hereinafter referred to as the improved groupcast messaging system withan aggregated acknowledgment along a single path, in what is known asthe improved unicast acknowledged message system. A need also exists forassigning any visual content into a group set of lamps, such content andgrouping is adaptable to anything the user desires and, if needed,scenes or content can be pre-defined within certain pre-assigned groups,so that when a group is selected, the content within the grouped lampswill produce the corresponding color, brightness or lighting effectsdesired. Sensing by one or more of the lamps is not needed in order toset the scenes, and thus the content within the lamps. A substantiallylimitless number of scenes can be chosen by a user or a select few canbe pre-defined, thus avoiding the detriments of the conventional networklighting control systems.

SUMMARY OF THE INVENTION

The following description of various embodiments of a lamp illuminationdevice interconnected through a wireless network to form a lightingcontrol system and method hereof is not to be construed in any way aslimiting the subject matter of the appended claims. Instead, thefollowing description outlines various solutions to the problemsdescribed above, wherein such problems are in large part solved by animproved lighting control system of lamps wirelessly interconnected, andin communication with a lighting controller, such as a computer with awireless interface and a graphical user interface (GUI).

According to one embodiment, a lighting control system is provided. Thelighting control system includes a plurality of lamps coupled togetherover a network, such as a mesh network. The plurality of lamps arewirelessly coupled, and communicate with each other over a WPAN using,for example, a communication protocol such as IEEE 802.15.4, oftentimesreferred to as ZigBee. The lighting control system, in addition to aplurality of lamps coupled to one another via a wireless network, alsoincludes a controller. The controller can be an execution device, suchas a computer that can execute upon software to generate a graphicaluser interface (GUI). The controller also has a wireless interface thatwirelessly communicates with the plurality of lamps. The GUI allows userinput to arrange icons representing the group of lamps, whereby eachlamp is shown on the GUI as a “virtual lamp.” Also shown on the GUI is anamed group icon, or an icon that simply has a name associated with thelocation and function of lamp icons, or virtual lamps, to be placedtherein. The named group icon can include, for example, a name such asbedroom downlight or bedroom night stand, or kitchen island, etc. Ascene is associated with the named group icon so that whatever virtuallamps are placed in that named group icon, all physical lamps located inthe residence and associated therewith will have stored content neededto reproduce the associated scene.

According to another embodiment, the named group icon need not bepre-named but can take on any name selected by user. Moreover, once thegroup icon is named, any of a substantially unlimited number of scenescan be associated with that named group icon. Therefore, a substantiallyunlimited variation of content can be downloaded to the physical lamps,as well as a seemingly endless variety of group names and addresses andspecifically group addresses assigned to the physical lamps.

Accordingly, the group names can be pre-defined, as well as the sceneassociated with each pre-defined group name. Note that the scene isassigned to the group icon, whereas the scene exists as content whenstored in the physical lamps. A bedroom night stand may be pre-definedon the GUI, as well as a pre-defined scene/show associated with thatgroup name. Therefore, a user need only assign certain lamps to thepre-defined group name and scene/show and, once assigned, any actuationon the assigned-to button will cause a control message to be sent to theappropriate physical lamp within the residence to turn on that lamp aswell as other lamps assigned to the group to activate those lamps withthe same scene or show.

Alternatively, neither the group nor the scene/show need be pre-defined.Instead, when lamps are assigned to a group, the group can be given anyname desired by the user. Also, instead of the group having apre-defined scene, the named group on the GUI having a correspondingpre-defined scene, than the group that is named by the user when virtuallamps are applied to that grouped named group icon, any of a numerousvariety of scenes (or content) can also be applied to that named groupicon the scene, which is static and is activated when a button isactuated and remains until another button is actuated can take on asubstantially unlimited variety of settings in color, brightness, or anyother type of lighting effect. If a show is desired, then actuating thebutton may activate a show which is nothing more than a scene as afunction of time to produce a desired circadian rhythm, or any othermodifications to color, brightness or visual effect that changes withtime, and until another button is actuated.

According to yet another embodiment, the lighting controller device thatcontrols the plurality of lamps not only provides a GUI to select groupsof physical lamps and assign those groups to specific scenes based ontheir function and location within a residence, but also during theprocedure of grouping and assigning a scene on the GUI (or content tothe physical lamps) a visual indicator on the lamp icon and the namedgroup icon is designed to correspond with a visual indicator from thephysical lamp and physical keypad control device. By visually indicatingon the physical devices (physical lamps and keypads within theresidence) and virtual devices (lamp icons and keypad icons) on the GUI,commissioning of lamps and keypads during a discovery procedure andthereafter during a grouping procedure can be visually confirmed by theuser. By indicating both in the physical realm as well as the virtualrealm, the user is assured that all of the physical devices have beendiscovered by the controller and, thereafter, grouped properly by thecontroller.

According to yet another embodiment, once all of the physical deviceshave been properly discovered and grouped, as well as grouped by sceneor show, a novel groupcast control and acknowledge procedure can takeplace. In essence, the grouping procedure groups not only lamps, butalso stored content associated with scenes and shows within the group oflamps and assigns that combination to a button. The button can be eitherthe button on a physical keypad control device or a virtual keypadcontrol device. As opposed to a physical keypad which is coupled withinthe residence to the AC mains and which wirelessly communicates with thelamps using, for example, ZigBee, a virtual keypad is what would appearon, for example, a mobile phone GUI. The virtual keypad would havebuttons similar to those shown on a physical keypad, yet those buttonswhich appear on, for example, the mobile phone would perform the samefunction as buttons on a physical keypad, yet the communication musttypically go through what is known as a bridge. A bridge is nothing morethan a transceiver between two different wireless communicationprotocols, whereby a mobile device, such as a smartphone may communicateusing a different protocol than, for example, ZigBee. A mobile devicemight communicate using the Ethernet, WiFi, or Bluetooth. The bridge isneeded to bridge the different wireless communication protocols of, forexample, the mobile phone to the lamps in order for the lamps to receivecommunication when a virtual button of a virtual keypad on thesmartphone is actuated.

When, for example, a button is actuated, the button number as well asthe keypad number can be sent as a control message to the network oflamps. Importantly, each of the lamps which are associated with a groupof lamps has a group address as well as a unique address. The groupaddress corresponds to a particular button depressed on a particularkeypad. Thus, once the button of a keypad is depressed, the groupaddresses are accessed on only the physical lamps which have a uniqueaddress associated with a unique group address for that button keypad.By using group addressing when assigning group addresses to uniqueaddresses that correspond to a particular button of a particular keypad,once a button of that keypad is actuated a broadcast signal need only beacknowledged by physical lamps having the corresponding unique groupaddress. This form of broadcast is hereinafter referred to as agroupcast. The benefit of using a groupcast methodology rather thanconventional unicast in a mesh lighting network is that the scene orshow assigned to that button that was actuated will activate all of thephysical lamps having the unique group address at substantially the sametime. Typical network lighting control systems use what is known asunicast control, where the first of many lamps receives the controlsignal, and that control signal is forwarded to the child lamp throughwhat is known as a hop. The procedure continues until all of the desiredlamps within the group are activated. A significant problem with thistype of unicast control is synchronization. Namely, all the lightschange with certain delay from one light to the other causing what isoften times referred to as the “popcorn effect.” By utilizing uniquegroupcast addressing scheme along with scenes corresponding to buttons,once a button is actuated according to the present invention, agroupcast signal is sent to turn on or off, or change the scene or show,at substantially the same time since all of the group of physical lampsreceived the command message at the same time without having to gothrough the conventional unicast hop mechanism.

A further advantage of the present groupcast control mechanism is that anovel aggregated acknowledgement message mechanism is employed. For eachof the group of physical lamps which receive the groupcast, those lampsmust return an acknowledge. In a mesh network, such as the presentnetwork, the acknowledge, if used, is sent across different lamp-to-lamppaths back to the control device so that the control device knows thateach of the group of lamps received the command message. Unfortunately,sending an acknowledge back on multiple, different paths can be timeconsumptive and can also add to the delay if, for example, one of thegroup of lamps does not turn on when instructed by the command message.Having to send back multiple paths of acknowledge, with one lamp notturning on, causes another message command to be sent by the controldevice to the lamp that did not acknowledge. The present acknowledgementmechanism avoids this problem by forming routing tables through use ofprevious acknowledged paths, and maintaining those routing tables toensure that an acknowledge from each of the group of physical lamps issent over the same path instructed by the previous routing tableacknowledgements and if by chance one lamp, or a select few do notacknowledge over that single path, they would acknowledge on possibly nomore than one or two different paths without requiring the controldevice to send another control message. The aggregated acknowledgemechanism over a single path is not only beneficial from a time delayperspective, but also can be dynamically altered through use of thepre-existing routing tables if a relatively few number of lamps do notacknowledge, which typically is the case in most settings since physicallamps generally stay put in the home. Thus, although the acknowledgemessage is unicast as a single message with aggregated unique addressesat the grouped subset of physical lamps that receive the groupcastcontrol message, the aggregated unique addresses of the group addressessubset is assured of being sent primarily as a single message and not asmultiple messages across multiple unicast path which would unduly hamperthe bandwidth of the control and acknowledge back mechanism.

BRIEF DESCRIPTION OF THE DRAWINGS

Other objects and advantages of the invention will become apparent uponreading the following detailed description and upon reference to theaccompanying drawings.

FIG. 1 is a plan diagram of a residence containing a plurality of lampsand control devices interconnected by a wireless network;

FIG. 2 shows an example of certain groupings of lamps based on locationand function;

FIG. 3 is a plan diagram of the network of lamps and control deviceswirelessly controlled directly by a controller such as laptop computeror indirectly by a controller such as a mobile phone;

FIG. 4 is a block diagram of a lamp, with a unique address for eachlamp, group addresses corresponding to a unique group of lamps andcontent stored in a memory of the lamp;

FIG. 5 is a block and plan diagram of controllers that control directlyor indirectly information stored in each of the lamps within a networkduring a commissioning or discovery procedure, followed by a groupingand scene selection procedure;

FIG. 6 shows an example of content associated with a scene, as well asunique and group addresses stored in lamps during the discovery,grouping and scene selection procedures;

FIG. 7 shows an example of the data file of the information stored inthe lamps during the discovery, grouping and scene selection procedures;

FIG. 8 is a flow diagram of the discovery procedure;

FIG. 9 is a flow diagram of the discovery procedure with acknowledgetimeout;

FIG. 10 is a GUI showing the discovery of lamps within a residence,followed by the selection and grouping of discovered lamps either tonamed groups having pre-defined scenes, or not;

FIG. 11 is a plan view of the actual physical lamp being discovered andgrouped in response to activities on the lamp icons of the GUI;

FIG. 12A is a GUI showing control devices, or physical keypads, beingassigned to groups by selecting a keypad icon on the screen andassociating same with at least one group, wherein the group shown on theGUI can be given any name via an entry onto the GUI, or can have apre-defined name such as bedroom downlight or bedroom night stand;

FIG. 12B is a GUI showing assignment or a scene or show to a button on acontrol device, or physical keypad, and wherein a pre-defined scene orshow can also be assigned to a button on a virtual keypad shown on a GUIof a mobile phone via an application;

FIG. 12C is GUI showing creation of any scene from among a substantiallyunlimited number of possible content variations and downloading theselected content to one or more groups of lamps;

FIG. 13A is a table showing an example of a button sending a controlmessage to retrieve a specific group address of grouped unique addressesof lamps from the physical or virtual keypad;

FIG. 13B is a table showing an example of a button sending a controlmessage to retrieve and activate content stored in a corresponding groupof lamps based on the desired scene or show;

FIG. 14 is a table showing a unique lamp address corresponding topossibly more than one grouping of lamps and therefore having more thanone group address, yet a single scene of contents stored therein;

FIG. 15 is a table showing a groupcast control messages sent from aphysical or virtual keypad control device and if one or more of thegroup of lamps that receive the groupcast control message do not respondwith an acknowledge message, unicast sending of an acknowledge messageback to the control device via the missing lamp;

FIG. 16 is a flow diagram of the groupcast message procedure followed bythe unicast acknowledge procedure of FIG. 15, with timeout;

FIG. 17 shows the unicast acknowledge message sent across a singlelamp-to-lamp path across the network of lamps to the control device; and

FIG. 18 shows aggregation of unique addresses of each of the group oflamps as the acknowledge message is sent across the single lamp-to-lamppath, with a separate path taken by a lamp unique address missing fromthe aggregated acknowledge message.

While the invention is susceptible to various modifications andalternative forms, specific embodiments thereof are shown by way ofexample in the drawings and will herein be described in detail. Itshould be understood, however, that the drawings and detaileddescription thereto are not intended to limit the invention to theparticular form disclosed, but on the contrary, the intention is tocover all modifications, equivalents and alternatives falling within thespirit and scope of the present invention as defined by the appendedclaims.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 illustrates an example of a residence 10 containing a pluralityof physical lamps 12 a, 12 b, 12 c, etc. The physical lamps aresometimes interchangeably referred to as simply lamps. Not all lamps arelabeled for sake of brevity in the drawings. A residence may havenumerous bedrooms, living rooms, rooms in general, and a significantnumber of lamps 12 can be arranged throughout that residence more orless than those shown in FIG. 1. Preferably, each lamp comprises atleast one LED and a communication interface for a first communicationprotocol, that communication protocol being a wireless communicationprotocol used by all of the lamps 12 within, for example, residence 10.A popular first communication protocol can be WPAN using IEEE 802.15.4and/or any protocol based thereon, like ZigBee. The lamps are arrangedin the various rooms, and have a specified function based mostly upontheir location. For example, lamps in the ceiling can be PAR lamps,whereas lamps in night stands, or next to couches can be A20 lamps.There can also be lamps such as wall lamps, or any other type ofconfiguration needed for a residence 10. For example, the living roomcan have four downlights, one of which is labeled 12 c, with A38 lamps,for example. The living room may also have lamps mounted on stands nextto a couch, or end table with A20 lights, for example, and labeled 12 d,12 e and 12 f. As an example to be used later, along with the livingroom, a bedroom can also have downlights, with two shown and labeled 12g and 12 h. Next to the bed on night stands can be A20 lights, marked aslamps 12 i and 12 j.

In addition to lamps interconnected to a wireless network, controldevices can also be interconnected. In the example shown in FIG. 1,physical keypads 14 a, 14 b and 14 c are also placed within residence10. As will be noted later, the physical keypads can be replaced byvirtual keypads, and assigned to, for example, a mobile phone, andspecifically the GUI shown on the mobile phone will appear identical thephysical keypads with virtual buttons similar to the actual buttons onthe physical keypads. The mobile phone can communicate using a differentwireless communication protocol, for communicating over a secondcommunication network. As opposed to the first communication protocol inwhich the physical lamps 12 and the physical keypads communicate, asecond communication protocol is linked to the first communicationprotocol via a bridge 16 that can be placed in proximity to theresidence and the residence 10 and can allow a second communicationprotocol such as Ethernet, WiFi, Bluetooth, etc. to communicate from,for example, a mobile phone to the lamps 12.

FIG. 2 illustrates an example in which lamps are grouped based on theirlocation and function. The mechanism for providing the grouping as wellas the function of the lamps will be disclosed later when describing thegrouping mechanism as well as the scene/show assignment mechanism.However, as shown in FIG. 2, a location such as the bedroom can have twogroups of lamps, a first group 18 a associated with group A to provide aparticular scene 1 or show 1 associated with the two downlights 12 g and12 h shown in FIG. 1. Because the downlights might need to be controlledseparate from the night stand lights, the downlights can be pre-assignedor assigned at any time by a user based on the desired function of thosedownlights. The two night stand lights can be placed in a differentgroup and have a different scene or show assigned to them, as shown bynumeral 18 b. For example, the downlights in group A, 18 a, can be madeto have a brighter output in a different color than the two night standlights, 18 b. Since each of the physical lamps has one or more LEDs, theRGB of the plurality of LEDs can be tailored to any color, brightness orvisual effect desired by the user.

In addition to the bedroom, the living room can also have its lampsassigned to groups, shown in labels 20 a, 20 b and 20 c. The fourdownlights within the living room can be assigned to a group C with aunique scene and show labeled scene 3 and show 3, whereas the end tablelight can have a group D and assigned a different scene 4 or show 4. Oneither end of the couch are two couch table lights that are assigned togroup E, and possibly to a scene 5 or show 5. By grouping the lamps andassigning lamps in those groups to different scenes or shows, virtuallyany type of lighting display can be achieved as desired by the user.

FIG. 3 illustrates a plurality of lamps 12 interconnected by a wirelesscommunication network. In addition to lamps 12 are physical keypads 14.The lamps can have any type of form factor including A20, PAR38, linearcove, wall washing lights, and track lights. The physical keypads can bemounted in a signal gang junction box and coupled to the AC mains.Moreover, virtual keypads can eliminate the physical keypads 14. Thevirtual keypads can exist on GUI applications on computers, andspecifically mobile devices like a smartphone. The keypads, whetherphysical or virtual, are typically described as “control devices.” Inaddition to the network of lamps 12 and physical keypads 14, acontroller is used to control the communication to and from the networkof lamps and keypads. Controller 22 a, similar to controller 22 b, isessentially an execution unit that executes on instructions and data topresent a GUI the user can use to perform the grouping and scene/showassignments. Control instructions are sent through a communicationinterface from controller 22 to the network of lamps and keypads. Thecommunication interface for controller 22 b simply communicatescorrectly to the lamps and keypads using, for example, ZigBeecommunication protocol. Controller 22 a, however, may communicate usinga different protocol than ZigBee, and therefore communication may gothrough a bridge or hub 24 that bridges between ZigBee protocol and theprotocol used by controller 22 a. For example, a software applicationcan operate on controller 22, possibly on either Apple or Android mobiledevices to present the virtual keypad on controller 22. Hub, or bridge24, bridges between WiFi and the wireless lamp network which can useZigBee. If controller 22 b is used, a dongle with a radio interface willallow the GUI of controller 22 b to communicate directly with thenetwork of lamps 12 and keypads 14.

A typical installation in a residence will have physical keypads and avariety of lamps in every room. In some cases, some rooms may havemultiple keypads controlling the same lamps just like conventional twoor three-way light switches. The physical keypads in each room thencontrol the color, brightness, spectrum, or visual effects in general.The keypads can control such effects either statically, or as a functionof time. A static control would simply be a user pushing a button on thephysical keypad. The lamps and physical keypads in a residence can alsobe controlled by a computer running an application with a radio-baseddongle plugged into a USB port, or can be controlled by a mobile device,such as a smartphone also running a software application. The dongle cancommunicate ZigBee messages directly, whereas the bridge, or hub 24converts between WiFi and the ZigBee messages, for example.

After the physical lamps and physical keypads are installed in theresidence 10, the lamps and keypads must be discovered before thegrouping and scene building procedures. Thus, a first step when using,for example, a controller with a dongle is to discover all the lamps andkeypads within range of that controller. The wireless network that thelamps 12 and keypads 14 use is preferably a mesh network, so lamps orkeypads that are physically distant may still be in communication rangeof the controller through one or more hops. When a user instructs thecontroller to discover all devices, possibly through a command on theGUI of the controller, the dongle broadcasts a message instructing alldevices that receive the message either directly or through any numberof hops, to respond with their unique ID number, often times referred toas the MAC address. The unique MAC address of each of the lamps, as wellas the keypads are sent back to the controller. The controller thendisplays on its GUI various icons on the GUI screen representing thephysical lamps that have responded. The icons are sometimes referred toas the virtual lamps since a need exists to distinguish between thelamps that appear on the GUI as virtual lamps and lamps that exist inthe residence, or physical lamps.

For example, in an installation with ten PAR lamps and five A20 lamps,and three physical keypads, fifteen virtual lamp icons with twodifferent types of lamps will appear. The keypads will appear at a laterstep also as keypad icons. An indication that all of the lamps have beendiscovered occurs when an acknowledge message is sent back from each ofthe lamps to the controller, which causes each physical lamp to turnblue, each physical keypad to blink. Moreover, each of the discoveredphysical lamps and physical keypads will appear as icons on the GUI. Ifall of the physical lamps do not turn blue or the keypads blink uponuser inspection by walking around the residence, not all acknowledgemessages have been returned and thus the missing acknowledge message ofthe unique MAC lamp address would indicate a non-blue physical lamp hasnot been discovered. Remedial measures would then need to be taken, asdescribed below. However, if all physical lamps turn blue on physicalinspection, then the corresponding icons will appear and all of thephysical lamps within the residence will appear as icons on thecontroller GUI.

After all of the physical lamps and physical keypads have beendiscovered, the next step is grouping. In the grouping procedure ormechanism, physical lamps that need to be controlled together areassigned a specific group address. As shown in FIG. 4, the variouscomponents of a lamp 12 are shown, including LEDs 26, processor 28,communication interface 30 and memory 32. During the grouping mechanisma group address, as well as pre-defined or non pre-defined contentassociated with that group are downloaded into memory 32 of each lamp 12thereafter, during a control mechanism, a single button actuation of aphysical keypad, or actuation of a group name assigned to a virtualbutton of a virtual keypad will cause a control message to be sent fromthe controller to address via a single groupcast message all of theunique MAC addresses associated with that unique group address to launchthe content associated with that group of physical LEDs viamicroprocessor 28 fetch mechanism to LEDs 26. Further descriptions ofthe group addressing, and storage of content within lamps 12 occurduring the grouping mechanism, as well as the scene builder or showbuilder mechanism.

FIG. 5 illustrates in more detail the different types of controllers, inparticularly the communication protocols applied to the plurality oflamps 12. A controller 22 b can simply include a dongle with a USBinterface and radio, the dongle is shown by reference numeral 34 pluggedinto the USB port of a computer, and the combination of both formscontroller 22 b. If controller 22 a is to communicate through a hub,then controller 22 a communicates using a different protocol then theprotocol at which the various lamps 12 communicate with each other, aswell as the physical keypad, if a virtual keypad is not used to replacethe physical keypad.

During the discovery phase, for example, the broadcast discovery signalis sent front the controller through the mesh network from hop-to-hop,as shown by FIG. 6, with an acknowledge back from, for example, uniqueaddress 17 to unique address 28 to unique address of 31, illustrated forexample in hexadecimal. The broadcast discovery and acknowledge backforms a routing table with a destination address and next hop addressshown in FIG. 7 for a particular lamp. The routing table is stored inthe memory of lamp 12, along with what we will describe later as thegroup address, as well as the content associated with that groupaddress. The group address and content can have a group address of, forexample F and C, respectfully, forming the groupcast table shown in FIG.7.

FIG. 8 is a flow diagram that illustrates the discovery procedure wherea lamp and device control manager, controller broadcast, for example, adiscovery message used to initialize the wireless network. At leastonce, after the lamps have been installed, a network configuration maybe necessary. Such a network configuration may be repeated multipletimes, for example, every day, every week, every month, or at randomtimes, or when powering on the lighting system or parts thereof. Thediscovery process can also be done if the network is reconfigured, iflamps are added or removed, or a modification of lighting scenes hasbeen made. When configuring the network during the discovery phase,controller at first has no knowledge about the available lamps. Thestructure of the network is not predetermined by installation like thecabling structure of a wired network. Instead, it may be determined bythe plurality of physical conditions, like the distance or shieldingmaterials between neighbored lamps, walls, or other devices between thelamps, or even by electromagnetic interference by electric appliances orother devices within the residence 10.

To compute the network configuration, preferably a broadcast istriggered by the controller 22. The broadcast message is transmitted byaddressing the messages to a pre-defined broadcast address, to which allphysical devices (lamps and keypads) are listening. For example, thebroadcast signal will be received first by those devices that are inclose proximity to the controller. Those lamps can then forward thebroadcast message to other lamps, which further forwards the message toeven further distal lamps via one or more hops. To complete the networkconfiguration, it is necessary that the controller receives anacknowledge signal from each lamp, by which the lamp acknowledges thatit has received a broadcast message. The acknowledge signal ispreferably transmitted as a unicast or directed message back to thecontroller that sent the broadcast. FIG. 6 illustrates the returnacknowledge message in the example of four lamps. Each lamp that sendssuch a unicast message must receive an acknowledge to prevent such lampsfrom resending the same message. Thus, as shown in FIG. 6, the returnacknowledge is sent by controller back through the mesh network, also asa unicast message.

During the discovery phase, or discovery process, it is fairly timeconsuming to broadcast, receive and acknowledge back, and thereaftersend an acknowledge reply. However, since the discovery process happensinfrequently, and only generally during the configuration of lampsduring initial install a time-consumptive discovery process that couldtake multiple seconds is generally acceptable to the user. However, whensubsequently controlling the discovered lamps, any time delay or lag,and especially any popcorn effect is to be avoided. Even a fraction of asecond, in some instances, is noticeably annoying to a user whenperforming control using the subsequently described groupcast andaggregated acknowledge mechanism.

Returning to FIG. 8, the discovery procedure, albeit relatively slowcompared to the control procedure begins with a broadcast discoverymessage 36 through which that message is routed through possiblymultiple hops 38 to all of the various nodes, including physical lampsand physical keypads 40. Each of those nodes, keypads and lamps unicastand acknowledge back to the controller 42, which must be routed as anacknowledge signal through the mesh network 44, whereupon the controllerthen receives the acknowledge hopefully having all of the unique MACaddresses of the physical lamps by indicating a blue light output fromall such lamps and a blinking physical keypad of the discovered keypads.

FIG. 9 illustrates the discovery mechanism in more detail, andspecifically illustrates a flow diagram of the timeout mechanism if anacknowledge back to the controller is not received in a specific amountof time. Similar to FIG. 8, a broadcast discovery message is sent from acontroller 22, and thereafter the controller 22 determines whether anacknowledge message is received from all of the physical devices(physical lamps and physical keypads) at step 50. If acknowledge isreceived at decision block 52, then the initialization, or discoveryprocedure is completed 54. If acknowledge is not received from all ofthe physical devices, then a counter is incremented 56. If the counterhas not limited out, then there is no need to send a unicast discoverymessage through the missing physical devices, or nodes. However, if thecounter has limited out, then a unicast message is sent as shown byblock 60, and another counter, a retry counter is initiated at block 62.The retry counter is incremented if it has not reached its limit 64, andthe procedure continues with checking for any received acknowledgesignals at step 50. If the retry counter has reached its limit, an errorflag is set at step 66. Although it is not critical, it is preferredhowever than an acknowledge received counter and a retry counter is usedas part of the discovery process, before the grouping process orprocedure can thereafter take place.

FIG. 10 illustrates the grouping procedure, where a GUI on thecontroller is used to group not only lamp icons, but also the physicallamps based on any group named by a user, or pre-existing groups withpre-existing scenes assigned thereto. FIG. 10 illustrates a GUIdisplayed on a controller 22. Upon the GUI, on a left hand portion ofthe GUI is an icon that represents either groups or keypads. When thegroups icon is selected, as indicated, a series of groups can appear.According to one embodiment a series of group icons 70 appear. Accordingto one embodiment, the group icons are not named until a user provides aname. Thus, for example, group A may be a name given to a group icon, orsimply could be a default name given to a group icon. According toanother embodiment, the groups shown as icons on the GUI of thecontroller 22 can have pre-defined names, such as the bedroom downlightor the bedroom night stand. In the latter embodiment, those pre-definednames may also have pre-defined scenes or shows. For example, thebedroom downlight may have a pre-defined scene or show that is uniquelyassigned to the downlights, or lamps in the bedroom as content stored inthat group of lamps. The uniquely assigned scene/show is preferablydifferent from the pre-defined scene or show associated with the bedroomnight stand group of lamps, for example. As shown in both FIGS. 10 and11, after all of the lamps have been discovered and appear as virtuallamps or lamp icons in the right portion of the GUI of FIG. 10, one ormore lamps can be grouped by clicking on the virtual lamp in the GUI andthat virtual lamp, or lamp icon, may blink or change to a differentcolor. The corresponding physical lamp within, for example, a bedroomwill also change color, or blink, as shown by physical lamp 12 gblinking that corresponds to a virtual lamp icon 70 a blinking. In thisfashion, the user will then know the correspondence between virtual lampicons and physical lamps so that when he or she performs the groupingprocedure it is known which lamp (virtual icon and physical) is assignedto each group as shown in FIGS. 10 and 11, where the bedroom down lamp12 g is assigned to group A according to one embodiment. According toanother embodiment, the physical lamp 12 g and its corresponding virtuallamp 70 a can be assigned to a pre-defined group called bedroomdownlight, that pre-defined group within the named group iconspreferably has a pre-defined scene or show so that whatever virtuallamps are placed in the corresponding named group icon, thecorresponding physical lamp will have stored contents that match thepre-defined scene or show and, when activated will display the contentsstored therein.

As an example, if there are three rooms with one keypad in each room(i.e., kitchen, living and bedroom), in the bedroom there may be two A20lamps on night stands and two PAR38 lamps in the ceiling. The user maywant to control these two groups of physical lamps independently so thattwo groups are created called bedroom downlights and bedroom nightstands, and these groups are shown as item number 70 in the GUI ofcontroller 22. In the living room, there may be three A20 lamps and fourPAR38 lamps. The user may want to create three named group icons 70comprising one A20 on an end table next to a chair, two A20s on eitherend of the couch, and four PAR38s in ceiling, so three groups arecreated called living-downlight, living-end table-chair, and living-endtable couch. The named group icons can be named by the user, or can bepre-defined with pre-defined scenes and shows associated therewith. Inthe kitchen, there may be four PAR38s in the ceiling that are controlledtogether, so a group called kitchen-downlight is created, or maypre-exist with an associated scene/show.

Using the example above, there are six groups of virtual lamp icons onthe left side, with ten PAR38 lamp icons (virtual lamps) and five A20lamp icons (virtual lamps) on the right side of the GUI. All the lightsare still blue. When a lamp icon is clicked on by the user, thecorresponding physical lamp and its associated MAC address changes colormomentarily, as shown when, for example, the virtual lamp icon 70 a isclicked on. The user will enter, for example, the bedroom and will notethe corresponding physical lamp 12 g changes color or flashes indicatingits correspondence to virtual lamp 70 a. The user then, for example,drags and drops the two virtual lamp icons into the group on the leftcalled bedroom-night stands, for example. This process can continue forthe other groups where, for example, the user can click on the PAR38virtual lamp icons until the two in the bedroom are identified and thendrags and drops those virtual lamp icons into the group calledbedroom-downlights. When a virtual lamp icon is dropped into a group,the associated physical lamp turns back to its default light color, forexample. The user can perform the same grouping procedure in the livingroom, kitchen, or throughout the residence 10.

At this point, all light icons on the right side of the GUI are gonesince they have been, for example, dragged and dropped into acorresponding group named group icon 70. Moreover, all of the physicallamps are producing white light. The next step is to configure thephysical keypads in each room. Configuration of the virtual keypadsusing, for example, a mobile phone control device will be describedlater. However, at the present, configuration of physical keypads isdescribed. When configuring the keypads, the user can click on adifferent tab, for example, tab B, rather than tab A shown at the top ofthe GUI, shown as item numbers 72 and 74 of FIG. 10. By clicking on tabB, for example, given any name, such as, for example, device controlrather than organization, the buttons on each keypad can be configuredto produce a particular brightness, color, spectrum setting and visualattribute setting for a particular group of lamps. The device controlprocedure of configuring specific buttons on a physical keypad is shownin more detail in reference to FIGS. 12a and 12b . For example,configuring a particular keypad begins by selecting the keypad, as shownin FIG. 12a as the selection of the virtual keypad icon 76 afterclicking on the keypad icon in the left portion of the GUI of controller22. Once the virtual keypad icon 76 is identified, keypad icon 76 can beassigned to a group icon 70 to be named or a pre-defined named groupicon. Thereafter, as shown in FIG. 12b , the GUI changes its display andpresents a virtual keypad, with corresponding virtual buttons 78. Fivevirtual buttons are shown, however, there couple be more or less buttonsas needed. A scene or show can be associated with a virtual scene/showicon 80 can then be selected and dragged and dropped onto thecorresponding button. In this fashion, each button on the virtual keypad76 can have an associated one or more groups of lamps within aresidence, and a corresponding scene or show assigned to each of thosegroup of lamps by downloading corresponding content to the physicallamps. Assignment of a group or a scene/show can also be performed froma dropdown menu, instead of drag and drop technique.

As an example, if there are two buttons that control thebedroom-downlight group and the bedroom-night stand group, the top twobuttons could control each of those groups. The user assigns aparticular color, brightness or any visual attribute to each of thevarious buttons and, in this case, the virtual buttons of the virtualkeypad 76. The bottom button, for example, can be assigned to all of thegroups controlled by the corresponding physical keypad, and the bottombutton can be assigned to turn all the lights associated with thevarious groups attributable to that keypad. The process describinggrouping of buttons to a bedroom can be repeated for the living room,the kitchen, and all of the remaining keypads within the residence,where physical or virtual keypads are selected and buttons of thosephysical or virtual keypads can be assigned to pre-defined or nonpre-defined groups as well as scenes and shows.

After programming into the various virtual buttons of the virtual keypaddisplayed on the controller 22 GUI, the corresponding group addressesand corresponding content of the assigned scenes and shows aredownloaded from the virtual keypad 76 to the physical keypad, such asphysical keypad 14 b of FIG. 1. The physical keypad will operateidentical to the virtual keypad, in that touching any buttoncorresponding to the five buttons on the virtual keypad will send agroupcast control message to the physical lamps being controlled by thephysical keypad. Moreover, similar to the identification of physicallamps when performing grouping of virtual lamp icons, the physicalkeypad associated with the virtual keypad 76 will blink when thatvirtual keypad is selected. For example, when virtual keypad 76 isselected within the GUI of controller 22, the corresponding physicalkeypad (e.g., physical keypad 14 b) will blink indicating to the userwhich keypad within the home has been selected.

As shown in FIG. 12b , along with the five virtual buttons 78 of thevirtual keypad 76, are up/down buttons 82. The up/down buttons are notprogrammed in the virtual keypad 76 but have a specific function in thephysical keypad. For example, once a corresponding button on thephysical keypad is actuated after having been programmed using thevirtual button on the GUI, the corresponding group of physical lampsturn on. The physical keypad may have buttons or touch lightscorresponding to the virtual slider lights 82, which are non-operable onthe virtual keypad but operable on the physical keypad to adjustbrightness of the lights controlled by the last button pushed on thephysical keypad. For instance, if the top button of the physical keypadin the bedroom sets the bedroom-downlight to red at half brightness, theup/down arrows would adjust the brightness of the bedroom-downlightafter the top button of the physical keypad is pushed. The up/downarrows would control the brightness of the bedroom-night stands after,for example, a third or fourth button on the bedroom physical keypad waspushed. During normal operation, when an up/down arrow is pushed, amessage is sent using groupcast addressing to the group of physicallamps associated with the keypad button.

According to one embodiment, the group assigned to a virtual button on avirtual keypad, and thus to the physical button on the physical keypadcan also be assigned to a pre-defined scene or show through use of adrop down icon 84. The drop-down notes the pre-defined scene or showapplied to a group, and through the GUI of controller 22, the group andits corresponding scene or show is applied to, for example, a virtualbutton on the virtual keypad 76 which then downloads that group, sceneor show to a physical button on the corresponding physical keypad thatwas blinking to indicate it was selected for programming. After all ofthe buttons have been programmed to their corresponding pre-definedgroup name with pre-defined scene and show, or according to anotherembodiment, to any user-defined, and non pre-defined group name or sceneand show, the physical keypad discontinues its blinking to indicate ithas been fully programmed.

According to one embodiment, if the scene and show was not pre-definedand assigned to a pre-defined group name, but instead is defined by auser to allow a button to take on any possible, substantially unlimitednumber of scenes or shows, a user can select the create scene or showbutton 86 as shown in FIG. 12. A corresponding GUI will then appear onthe controller 22 as shown in FIG. 12c . The GUI allows the user tomanually control any color, brightness or visual attribute to beassigned, by clicking on the manual control 88. The manual control canthen bring up a blackbody curve to allow a user to pick any color alongthat blackbody curve 90, or to select any other visual attribute, suchas CCT, tint, vibrancy, red green blue (RGB), brightness, etc. usingsliders 92 for each. Moreover, the user can assign times, either inincrements or time of day 94, for each attribute, color or brightness toproduce what is herein described as a show. The time can be programmedto for example daytime or nighttime to change brightness from thebrighter daytime demand to a less bright nighttime demand, or tosynchronize with the circadian rhythm of a user. If manual control isnot desired, then the various color brightness and visual attributes canbe drawn from a content library by clicking on icon 96, and assigning toeach button the corresponding content from library 96. FIG. 12illustrates what is known as a scene or show builder that, once createdby clicking on button 86 and the GUI in FIG. 12c appearing, the createdscene or show can then be assigned by thereafter clicking on button 80,for example, an assigning that created scene or show to a correspondingbutton on the virtual keypad, and thereafter downloading as content tothe corresponding group of physical lamps whenever the correspondingbutton of the corresponding physical keypad is actuated. Thereafter,during a groupcast control message being sent when a button of aparticular keypad is actuated, the keypad address and the button addressis all that need be sent from the physical keypad to the correspondinggroup addresses of the physical group of lamps having correspondingcontent assigned to them by virtue of the assignment of the scene orshow to the virtual keypad buttons and therefore to the physical keypadbuttons. FIGS. 13a and 13b show this correspondence, along with FIG. 4.In particular, a keypad, such as physical keypad 1 within, for example,the bedroom can have five physical buttons. Each button can be assignedto a group of lamps as well as a scene (or show). By actuating button 4,for example, the group of physical lamps associated with group F areaddressed when button number 1 of keypad 1 is sent within the payload ofthe control message. Button 1 of keypad 1 may then correspond to aunique group address within each of the physical lamps that have anindex to the unique MAC addresses for those lamps. For example, whenactuating button 4 of the physical keypad 1, keypad 1 and button 4 aregroupcast to address the MAC addresses of lamp addresses 31, 28 and 17to turn on those lamps in accordance with scene B stored as contentwithin those lamps, and shown in FIG. 13b . Thus, the improved controlmessage is one having a simple, shorted payload needed to send only thephysical keypad address and its corresponding button address, which willthen be decoded by the physical lamps that receive the groupcastmessage, and specifically only by lamps having the corresponding uniquegroup address, and specifically the unique MAC addresses of each ofthose lamps associated with that unique group address. By only sending akeypad address and a button address, the groupcast message is one havinga fairly small payload, and thus can achieve a faster decode on each ofthe unique addresses associated with the unique group address stored ina database within each of the physical lamps. This guaranteed groupcastmethod is further described in reference to FIG. 15. However, suffice itto say that within each physical lamp, and specifically the memory ofeach physical lamp, a lamp has a unique MAC address such as hexadecimaladdress 31 shown in FIG. 14. Moreover, each physical lamp also storesone or more unique group addresses as well as content. The unique groupaddresses for lamp hexadecimal 31 can be group F and H, and also containcontent B. The data file of the lamp memory associates the uniqueaddress 31 with the group address, such as group address F, and actuatescontent B when a particular button preprogrammed to group F and scene Bis actuated.

As shown in FIG. 15, when the button is actuated or pressed on thephysical keypad, or as described later, the virtual keypad of controller22, the button number and keypad number is sent within the payload ofthe groupcast control message. Alternatively, the group addresses can besent. The button number, keypad number, or the group addresses arereceived on the physical lamps 12 and an acknowledge signal is unicastback to the controller 22. If not all physical lamps 12 send back andacknowledge signal as detected by the controller 22, a unicast signal issent from controller 22 to the particular unique address of the missingphysical lamp, from hop-to-hop until it arrives on the missing physicallamp, 12Y, for example, which then sends back an acknowledge signalunicast to the controller 22 further details of the novel guaranteedgroupcast, with aggregated single message acknowledge is describedfurther in reference to FIGS. 17 and 18. Similar to the timeoutmechanism of the broadcast discovery signal, FIG. 16 illustrates a flowdiagram of the groupcast control signal 100, where an acknowledge ischecked by the controller 102 and if an acknowledge is received 104,transmission is completed 106. If an acknowledge is not received by thecontroller at decision block 104, then a counter is incremented 108 andif the countdown has occurred before an acknowledge is received, then aunicast message 112, as shown in FIG. 15 is sent from the controller 22to increment a retry counter on the unicast response 114. If the retrycounter reaches its limit 116, then an error flag is set 118. If theretry counter does not reach its limits before an acknowledge is sentback from, for example, missing node 12 y as shown in FIG. 15, then allacknowledge messages from all physical lamps within the group have beenreceived.

Turning to an embodiment in which a mobile application is used, such asone stored within a smartphone operating under the Apple or Androidoperating system, the various named group icons can be pre-named orpre-defined, shown in FIG. 12a . Moreover, as shown by reference numeral70 in FIG. 12a . Moreover, the scene and show attributable to thepre-defined named groups can also be pre-defined as shown by icon 84 inFIG. 12b . Instead of a user associating basic information such as thescene and show from a variety either manually or from a content library,as shown in FIG. 12c , the mobile application can automatically loadpre-defined content into the physical lamps when each lamp is assignedto a particular group, or subgroup. When using a mobile app, thediscovery step operates the same way as before, with the bridge or hubbroadcasting the discovery command or message, in every physical device(physical lamp and physical keypad) within communication range responsewith its unique address. The hub then acknowledges receipt of eachresponse and sends an internet protocol (IP) message to the mobiledevice with the list of physical devices in the system.

While the discovery step is the same, the grouping and scene assignmentstep or procedure is different. Instead of creating arbitrary names forgroups of lights using the GUI of a controller, as in FIG. 12a , thosenames can be pre-defined, as shown in the lower two groups 70 of FIG.12a , for example, importantly associated with each group in the listare different sets of scenes or shows, which translates to differentsets of pre-determined content to be stored in the physical lamps. Thepre-defined list of groups typically would include different types ofrooms, such as kitchen, bedroom, living, dining, entry, closet, hall,bath, etc. The groups can also be defined with more granularity, such askitchen-island, kitchen-range, kitchen-downlight, living-wall,living-table, master-night, master-table, and master-down, etc.

Once the list is complete, the user associates each lamp icon displayedon the mobile app from the discovery step with a physical lamp and dragsand drops that icon into the desired pre-defined group having apre-defined scene or show. When this association is made, a message issent to the group of physical lamps that contain the content for thoselamps. The content includes color, spectrum, brightness, etc., eitherstatic or as a function of time, including location, weather, etc.,called scenes, or, if a function of time, shows. The pre-determinedscenes or shows are sent to the lamp and stored in the lamp non-volatilememory. The content or scenes loaded into each physical lamp during thisassociation or grouping procedure depends on the groups associated witheach lamp. The group address for each group, if they exist, is alsoloaded into the physical lamp and non-volatile memory at this time.

When using a mobile app with pre-defined scenes or shows and thosepre-defined scenes and shows assigned to pre-defined and pre-namedgroups, the need for creating names and assigning scenes or shows toeach of the named groups is unnecessary. Moreover, downloading groups,scenes and shows to particular buttons on a physical keypad is alsounnecessary. Each of the buttons on the mobile device is alsounnecessary. The mobile device can contain as its GUI the keypads andspecifically the buttons of the keypads, therefore eliminating the needfor a physical keypad. The virtual keypad icons on the GUI of the mobiledevice operate just like the physical keypad that are hereinafterreferred to as a virtual keypad, with virtual keypad buttons. Thevirtual keypad buttons are assigned to one or more groups, each virtualkeypad button also assigned to a scene or show. Therefore, instead ofassigning, for example, color, spectrum, brightness, CCT contents to thelamps in the specified group, a scene number 4 of the group is assignedto each button. The scene numbers in the associated keypad button numberare sent through the groupcast message to the members of all the groupsassociated with each keypad button. During normal operation, when avirtual keypad button is pushed, groupcast messages are sent to thegroup of physical keypads associated with each keypad button indicatingwhich button was pushed. Each lamp then performs the associated scenepreviously stored in the lamps non-volatile memory. The differentbuttons on the keypad can be programmed to control different groups oflights within a room, or to trigger different scenes stored in thenon-volatile memory.

With the mobile application, there is no need for physical keypads, andthe lighting control system can be controlled by virtual keypads thatreside within the mobile app. Such virtual keypads are configured and dooperate the same as the physical keypads. The mobile application has amain control page that provides buttons for all virtual keypads, forinstance, one in each room.

Broadcast messaging is essential for the initial device discoveryprocedure. Such broadcast messaging elicits a response from all physicaldevices that receive such messages. The response messages are unicastback to the source address, and in this case the controller, that sentthe broadcast message. Such unicast messages may go directly back to thecontroller, or they may take one or more hops through the mesh network.Each physical device that sends such a unicast message must also receivean acknowledge back to that device to prevent that device from resendingthe same message. In a typical mesh network, the acknowledge is sent bythe receiving controller or, in the case of a mobile phone, by the hub.

The broadcast discovery message may pass through many hops to an endphysical device, or physical lamp, and the response may pass through thesame number of hops to the controller, and thereafter anotheracknowledge may again pass through the same number of hops to the endphysical lamp. Since every physical lamp must respond and beacknowledged, the discovery process can create a significant amount ofmessage traffic. However, since the discovery is not necessarily timecritical and is seldom performed, this is not a significant issue.

Beneficially, the content associated with scenes is stored in thephysical lamp non-volatile memory instead of in the physical or virtualkeypads to reduce network message traffic. When a button is pushed, onlythe button number is groupcast to the group addresses associated withthat button. Such groupcast messages contain the source address in theheader, so the physical lamps know which keypad (physical or virtual) issending the message in case multiple keypads control the same group. Allphysical lamps in a group must acknowledge receipt of the groupcastmessage. If not, the system will not know if one physical lamp forinstance did not receive the message to turn off and, as such, stays on.In the case of a system with physical keypads, the individual addressesof each member of the group associated with buttons on that keypad canbe stored in the keypad non-volatile memory.

When a button that controls one group for instance is pushed, oractuated, one groupcast message is sent indicating which button waspushed. All members of that group must respond with an acknowledgemessage to the keypad. Such acknowledge message may pass directly from aphysical lamp to the keypad or may go through many hops. If the keypaddoes not get an acknowledge from a device within the group the keypadsends a unicast message to unresponsive devices directly until thekeypad receives an acknowledge back. This is described in reference toFIGS. 15 and 16. The keypad thus guarantees that all members of thephysical lamp group received the groupcast message.

A groupcast message from a keypad (whether physical or virtual) cangenerate a significant amount of acknowledge message traffic. Althoughthe acknowledge message is needed to guarantee the groupcast wasreceived, the acknowledge does require traffic bandwidth. In a largemesh network, for example, in which acknowledge messages must take manyhops, the traffic can slow network response time significantly. At somepoint, the delays will become obvious to a user. For instance, if onephysical lamp does not receive the groupcast message to turn off, thetime the keypad needs to determine this and send a unicast message maybe on the order of seconds, which may be unacceptable to a user.

To minimize such acknowledge delays, it is important that one minimizethe number of messages to take to multiple hops. To do so, theacknowledge message is aggregated using the novel single message appaggregated methodology described in FIGS. 17 and 18. Since lamps aretypically stationary, the path that acknowledge messages take throughthe mesh network typically does not change significantly. As such, eachphysical lamp node operates as a router, with routing tables stored inthe lamp non-volatile memory. The routing tables keep track of theacknowledge message traffic passing through the mesh network, fromphysical lamp to physical lamp. For instance, if three lamps at the farend of the hallway always hop their acknowledges through a particularfourth lamp, the fourth lamp stores the addresses of the first threelamps. This is shown in FIG. 17, where the fourth lamp stores theaddresses of the acknowledge back messages of the more distal lamps,with addresses 31, 38 and 17 as shown. When a subsequent groupcastmessage is sent, the fourth lamp 124 will wait to receive acknowledgemessages from the other lamps with addresses 31, 28 and 17. Once allthree acknowledge messages are received at the fourth lamp labeled 124,the fourth lamp will send one message, and only one message, to thekeypad (virtual or physical) that includes acknowledgment from all fourlamps, including lamp 124 in that single message. Using a single messageaggregated address acknowledge back mechanism substantially reducesnetwork message traffic and associated latencies.

If the fourth lamp receives acknowledge messages from only two of thethree first lamps, such as that shown by reference 126 of FIG. 18, andthose addresses for those two lamps 28 and 31 are only sent after acertain timeout period, the fourth physical lamp 124 sends anacknowledgement from only itself and the two lamps back to the keypad.Thus, appended, or aggregated to the single message 126 will also be thepayload acknowledge address for lamp 124 having, for example, an addressof hexadecimal 40. Thus, the aggregated payloads of only three physicallamp addresses are sent back to the keypad. In this case, however, thethird lamp, with a hexadecimal address 17, for example, will dynamicallyadjust based on the pre-stored routing tables to have sent itsacknowledge through another lamp-to-lamp route to the keypad. Forexample, the payload acknowledge hexadecimal address 17 can be sentdirectly to the keypad, or appended (or aggregated) with other missingphysical lamp addresses. The routing of acknowledge is dynamic and canreadily change based on the pre-stored routine tables. Importantly,acknowledgement is guaranteed so as to ensure that the groupcast messageis also guaranteed. Thus, delivery of the groupcast message throughacknowledgement and minimization of the acknowledge message trafficusing minimal acknowledge message pathways (preferably only one) isachieved by maintaining routing tables and combining or aggregatingknowledge messages.

The routing tables can be established for each hop is defined by thesource and destination addresses, as shown in FIG. 7. The routing tablescan be also established during the discovery procedure. The networklayer of the OSI model manages mesh or routing within, for example, aZigBee network using such routing tables in each full function deviceand network headers within the MAC message payload. The network headercomprises the addresses of the original message source and the finalmessage destination in a unicast message. Such messages may make manyhops through the mesh network. The route through the mesh network that aunicast message takes is determined by routing tables within routingcapable devices, such as the physical lamps herein. When a routingdevice (physical lamp) receives a message with a destination address inthe network header that matches an address in its routing table, therouting lamp device retransmits the message with the destination MACaddress sent to the address of the next device in the path to theeventual destination. By knowing for each physical lamp the parent andchildren addresses, messages are sent with the packetized address beingthe unique address of the next hop node, or physical lamp. Routingtables should be set up to minimize the number of hops between thecontroller and every physical lamp. Each hop however, must have somelevel of link quality to ensure reliable communications. A possibleprocedure for setting up a network could be one in which the controllersends out an initiation message three times with its unique sourceaddress. Every physical lamp that receives such a message sends aunicast message back to the controller indicating how many initialmessages it received in an indication of the received signal screen. Thecontroller then instructs each identified child physical lamp to send aninitial message three times with its unique source address. Child lamps,or devices, of the controller do not respond. When a successive child ofthe controller sends its initial message, children of another child donot respond either. This process continues until no devices respond tothe initial messages.

When the network powers up each time, or when just some number ofphysical lamps are powered off and then on again, routing tables can bere-initialized which dictate the path that unicast messages take throughthe mesh network. In the discovery procedure, a physical lamp broadcastsa route discovery command with an ID in the destination address. Anyrouting capable device, such as the physical lamp, that receives suchmessages creates an entry comprising the ID, the address of thebroadcasting device, and the destination address and re-broadcasts themessage. The radius in hops is decremented each re-broadcast. Once there-broadcast message reaches the destination, the destination responsewith a message to the device that was the last to re-broadcast themessage. That device then creates a routing table entry after receivedsuch message indicating destination address and next topic address. Onceall unicast routing tables are setup, groupcast acknowledge tables aredetermined. Similar to the unicast routing tables, the groupcastacknowledge tables shown in FIG. 17, for example, are provisioned sothat the controller knows from provisioning the addresses of all of thephysical lamps in each group. Groupcast messages or messages to change ascene must be acknowledge by every physical lamp in each group therebyaddressed. The scene is changed when each device receives the groupcastmessage, and the keypad or controller receives the acknowledge a shorttime later. If all acknowledges do not come back, the controller cansend unicast messages to those devices that did not acknowledge. Theacknowledge messages are combined or aggregated by the routing devicesas they progress back to the controller to reduce network traffic.

Once all of the physical lamps have been grouped, the controllerunicasts using the routing table. The unicast message is sent to thegroup to each of the physical lamps so that those lamps contain not onlytheir unique MAC addresses but also the group address. Each keypad(physical or virtual) must know the unicast address of every lamp ineach group in order to guarantee groupcast. Thus, each button of thekeypad knows the corresponding unique groupcast address but also withina data file the corresponding unique MAC address of every physical lampwithin that group.

During the initial discovery procedure broadcast occurs from thecontroller with some maximum radius. Each physical lamp sends a unicastmessage back down the mesh network to the controller. The controller hasthe address of all nodes, but routing tables are not yet set up. Thecontroller issues route discovery commands to every physical lamp, whichsets up routes for the controller through all routers within eachphysical lamp to each subsequent lamp. Lamps are assigned to groups, andthe group addresses are unicast to each lamp. The group addresses andthe unique addresses of each lamp are then used as part of thesubsequent command message procedure.

Keypads would already have identified themselves and the controllerwould have discovered routes and set up routing tables to each keypad.During provisioning, the groups associated with each button, along withthe unicast addresses of the physical lamps in each group are unicast toeach keypad. The controller discovers the routes to each keypad and thekeypads respond down the mesh tree to the controller. The scenesassociated with each button can then be groupcast or unicast to all ofthe lamps.

Groupcast is basically the same as broadcast, but with a group addressin the payload of the message. The group address, however, can be in theform of simply a bit in the header specifying group or unicastmessaging, as well as a button number and keypad number within thepayload. Groupcast messages are broadcast with some radius, with routingtables being interrogated to determine whether or not the groupcastmessage should be re-broadcast by any particular routing capablephysical lamp.

By using routing tables, and also setting up an acknowledge routingtable, the groupcast control message is guaranteed to be received oneach of the group of lamps having a corresponding group address. Thisresult is in part, due to each of the group of lamps sending back anacknowledge signal. Importantly, the groupcast signal is preferably sentto each of the group of lamps at substantially the same time and,through use of the acknowledge routing table, a single pathway ispreferably achieved using an aggregated payload of unique addresses ofthe group of physical lamps that receive a groupcast signal. Thecombination of using a groupcast signal with group addresses and anaggregated, single pathway acknowledge signal achieves not only aguaranteed groupcast but also a groupcast with minimal delay relatedartifacts, such as not all lights changing at the same time.

It will be appreciated to those skilled in the art having the benefit ofthis disclosure that the invention is believed to provide an improveddownloading mechanism of visual content into lamps after assigning suchlamps to a group, and also to guarantee broadcast and groupcastmessaging necessary to illuminate lamps in a mesh network withoutvisible delay related artifacts. Further modifications and alternativeembodiments of various aspects of the invention will be apparent tothose skilled in the art in view of this description. It is intended,therefore, that the following claims be interpreted to embrace all suchmodifications and changes and, accordingly, the specification anddrawings are to be regarded in an illustrative rather than restrictivesense.

1-5. (canceled)
 6. A lighting control system, comprising: a plurality oflamps interconnected within a residence by a wireless network; a subsetof the plurality of lamps corresponding to a group of lamps having thesame pre-defined scene or show content stored therein based on theirfunction and location within the residence; and a control devicecomprising a button which is configured to forward a groupcast messageaddressed to only the group of lamps and to activate the group of lampsat substantially the same time based on their stored content.
 7. Thelighting control system as recited in claim 6, wherein each lamp of thegroup of lamps comprises: at least one light emitting diode (LED); amemory for storing the pre-defined content and a plurality of addressesof the group of lamps; a processor coupled between the LED and thememory for sending an activation signal to the LED when the messagecauses the processor to fetch from the memory an address from among theplurality of addresses of the group of lamps.
 8. The lighting controlsystem as recited in claim 6, wherein the pre-defined content isselected from a library of content prior to assigning the subset of theplurality of lamps to the group of lamps.
 9. The lighting control systemas recited in claim 6, wherein the pre-defined content comprises colorand brightness.
 10. The lighting control system as recited in claim 9,wherein the pre-defined content further comprises chromaticity,spectrum, vibrancy and tint.
 11. The lighting control system as recitedin claim 6, wherein the pre-defined content comprises color, brightnessand chromaticity as a function of time.
 12. The lighting control systemas recited in claim 11, wherein the pre-defined content furthercomprises chromaticity, spectrum, vibrancy and tint as a function oftime.
 13. The lighting control system as recited in claim 6, wherein thenetwork comprises a mesh wireless personal area network (WPAN).
 14. Thelighting control system as recited in claim 13, wherein the WPANcommunicates among the plurality of lamps using an IEEE 802.15 or ZigBeecommunication protocol.
 15. The lighting control system as recited inclaim 6, wherein the control device comprises a keypad coupled to the ACmains of the residence and in communication with the wireless networkvia a button arranged on a face of the keypad.
 16. The lighting controlsystem as recited in claim 6, wherein the control device comprises: amobile device comprising a radio transmitter; and a graphical userinterface for displaying a button wherein, upon activation of thebutton, the mobile device forwards the groupcast message. 17-19.(canceled)